(19) 



J 



Europaisches Patentamt 
European Patent Office 
Office europeen des brevets 



(12) 



(43) Date of publication: 

02.01.2003 Bulletin 2003/01 



(n) EP 1 271 861 A2 

EUROPEAN PATENT APPLICATION 

(51) lntCI.7; H04L 12/56 



(21) Application number: 02254403.5 

(22) Date of filing: 24.06.2002 



(84) Designated Contracting States: 


(72) Inventors: 


AT BE CH CY DE DK ES Fl FR GB GR IE IT LI LU 


• Watson, Thomas Lee 


MC NL PTSETR 


Richardson, TX 75082-3788 (US) 


Designated Extension Stetpsj 


• Visser, Lance Arnold 


AL LT LV MK RO SI 


Dallas, TX 75252 (US) 


(30) Priority: 29.06.2001 US 896228 


(74) Representative: Jackson, Richard Eric et al 




Carpmaels & Ransford, 


(71) Applicant: Chiaro Networks Ltd. 


43 Bloomsbury Square 


Richardson, Texas 75080 (US) 


London WC1A2RA (GB) 



(54) System and method for router virtual networking 



(57) A host router 1 0 is logically partitioned into vir- 
tual router domains 12, 14, 16 that manage independent 
processes 22, 23, 24, 25 : 26 and routing application 
copies but share a common operating system 18, 20. 
Each v-net manages an independent set of sockets 32, 
33, 34, 35 36 and host router interfaces 42, 43, 45, each 
associated with only one v-net at one time, but inter- 
changeably repartitionable Traffic is removed from an 
interface during repartitioning. Duplicate arrays of global 



variables copied to each v-net are accessed by macro 
references. A v-net facility can separate route tables 46, 
48, 50 used internally from the externally visible route 
tables and can avoid conflicts between internal and ex- 
ternal IP addresses 13, 15, 17 that share the same iden- 
tifier. For example a common FreeBSD operating sys- 
tem supports a dynamic routing protocol (DRP) applica- 
tion 23, 25. Each v-net runs an independent copy of the 
DRP software and is logically independent. A failure in 
one DRP copy does not adversely affect other copies. 



CM 
< 

r- 

CD 
00 

N 
CM 



Q. 

LU 



INTERNAL 
MANAGEMENT 22 
DOMAIN / 



13 



MANAGEMENT 
APPUCAT10N 



DESCRIPTOR 
UST 
32-0 



32-2 



A Vnet IC 
12 

USER 



v18 



KERNEL 



^20 



SOCKET 



Vnet ID | 

7 



35-4 



13 



SOCKET 
I Vnet ID I 

' 7 1 



33-4 

I 



SOCKET 
1 Vnet ID | 



13 



ROUTING 
TABUS 



T 

46 



32-3 



13 



OTHER 
VIRTUALiZED 
VARIABLES 



42-1- 



INTERFACE 
LET 



42-0 



L 

42- 2 A 
42-3 



NET INTERFACE 



I Vnet ID | 



13 VnetO 



VIRTUAL 
ROUTER 1 



Vnet ID 
23 15 ' '24 
; H I 



DRP 
APPLICATION 



DESCRIPTOR 
UST 
33-0 



33-2 

L— 



SNMP AGENT 
APPLICATION 



DESCRIPTOR 
LIST 
34-0 



33-1 



34-3 34-2 



SOCKET 
| Vnet ID I 



~r 
— i — 

15 



34-1 



SOCKET 



Vnet ID 



ROUTING 
TABLES 



48 



33-3 
47- 



15 



OTHER , 
VIRTUALIZED 
VARIABLES 



43- Wf 



INTERFACE 
UST 

43-0 



L 

43-2-^ 
43-3 



NET INTERFACE 



Vnet ID 



15 »VneU 



i 1 



xi A Vnet {p i 



VIRTUAL 

ROUTER 2 25 '"" " ' 26 
L L 



DRP 
APPLICATION 



DESCP 
LI 
35 


1PT0R 
ST 

z2 


35-2 


35-1 

-A 


-V 


i 



SNMP AGENT 
APPLICATION 



DESCRIPTOR 
UST 
36-0 



36-3 36-2 



SOCKET 
Vnet ID \ 



36-1 



17 



ROUTING 
TABLES 

7 



35-3 



SOCKET 



Vnet ID 



17 



47^ 



OTHER 
VIRTUMJZED 
VARIABLES 



50 45- K 



INTERFACE J NET INTERFACE 

LIST L 

—? 45-2^ 

45-0 45-3' 
_ \ 



Vnet ID 



Vnet2 ' 



-10 



Printed by Jouve, 75001 PARIS (PR) 



BNSDOCID: <EP 1271B61A2 I > 



1 



EP 1 271 861 A2 

Description 

RELATED APPLICATIONS 

5 [0001]- This application is related to co-pending and commonly assigned U.S. Application Serial Number 09/703,057, 
entitled "System And Method For IP Router With an Optical Core," filed October 31 , 2000, the disclosure of which is 
hereby incorporated herein by reference. 

TECHNICAL FIELD 

10 

[0002] This application relates to the field of communication networks, and particularly to large-scale routers for 
optical communication networks. 

BACKGROUND 

15 

[0003] Transmission Control Protocol (TCP) is an underlying connection protocol that is typically used for all types 
of network communication. A route is essentially the mapping of an IP address to an egress port of a router. Different 
network routers set up connections with their peer routers using operating systems, for example Border Gateway 
Protocol (BGP) over TCP or OSPF (Open Shortest Path First) over Internet Protocol (IP) to determine that they get 

20 route information from their peers, allowing them to construct essentially an internal map of the network and to select 
the route that they should use, as well as verification that their peers are operating correctly. This is accomplished by 
sending various keep-alive packets back and forth to make sure that their peers are still correctly functioning. Routes 
are used internally within a router, for example a Master Control Processor (MCP) communicates through an Ethernet 
control network (CNET) within a router with the shelf control processors, each of which have individual IP addresses. 

25 Processes including routing applications, for example Dynamic Routing Protocol (DRP), run on these operating sys- 
tems. Sockets are end points of communication associated with a process. A particular process can have more than 
one socket. 

[0004] In a router with a large number of ports, for example 320 ports, that communicates with peer routers, it is 
advantageous to subdivide that single large router logically into several smaller virtual routers, each of which can be 
30 individually configured. There can be separate departments in a large company, or an Internet provider wanting to 
partition a large router among clients, for example for security reasons. However, previous implementations of subdi- 
viding routers having large numbers of ports have been cumbersome. 

SUMMARY OF THE INVENTION 

35 

[0005] The present invention is directed to a system and method which logically partition a host router into virtual 
router domains that run independent processes and routing application copies but share a common operating system. 
Each v-net domain manages an independent set of interface ports. Each process manages an independent set of 
sockets. 

40 [0006] In some embodiments a v-net domain architecture is used to partition a host router. Some v-net domains 
1 support virtual routers, whereas other v-net domains support only internal router processes and management appli- 
cations. Thus, not every v-net domain supports a virtual router. A single v-net domain can support more than one 
process. A v-net facility can advantageously separate route tables used internally from the externally visible routes, 
making network management easier and more transparent. With separate v-net domains for example, the IP address 

45 of an internal shelf control processor does not conflict with the same IP address that is assigned elsewhere on the 
Internet. In a v-net implementation, duplicate arrays of global variables are instantiated in each virtual router domain 
and are accessed by macro references. 

[0007] A common FreeBSD operating system running on the MCP supports a dynamic routing protocol (DRP) ap- 
plication. Each new virtual router is independently managed by its own copy of the DRP application for as many virtual 

so routers as exist. If something goes awry in one DRP copy, it does not affect other copies. Each v-net domain manages 
a separate set of the interfaces associated with the host router, which provide connections to peer routers. For example, 
if a host router has 320 ports : one v-net domain can manage 120 ports or interfaces, and another v-net domain can 
manage another 1 20 ports. All of these ports and interfaces can be interchangeably partitioned. For each Synchronous 
Optical Network (SONET) port on a line card, there is an interface (IF) data structure in FreeBSD that represents that 

55 SONET port. Any interface can be associated with only one v-net at one time, but can be moved among v-nets to 
reconfigure the host router. Traffic is removed from an interface while it is being moved. At a high level the host router 
is partitioned, and each partition normally is managed by an independent copy of the DRPsoftware. In an administrative 
sense, each of these partitions is logically independent. 
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[0008] Certain activities are still managed across the entire host router, for example failure reporting of hardware in 
the host router, which is machine specific, and therefore is a resource shared by all of the partitions. 
[0009] This partitioning also allows the routes between the individual components such as the line cards and proc- 
essors internal to a router to be contained in route tables separate from externally visible routes. Partitioning the router 
5 also facilitates testing, such that one partition might be used for normal network traffic and another might be used to 
test for example new software or new network configurations for new types of protocols. Additionally, a degree of 
redundancy is achieved, such that failure of one partition generally does not adversely affect another partition sharing 
the same host router. 

[0010] Various aspects of the invention are described in co-pending and commonly assigned U.S. Application Serial 
10 Number 09/703,057, entitled "System And Method For IP Router With an Optical Core," filed October 31 , 2000, the 
disclosure of which has been incorporated herein by reference. 

[0011] The foregoing has outlined rather broadly the features and technical advantages of the present invention in 
order that the detailed description of the invention that follows may be better understood. Additional features and 
advantages of the invention will be described hereinafter which form the subject of the claims of the invention. It should 

15 be appreciated by those skilled in the art that the conception and specific embodiment disclosed may be readily utilized 
as a basis for modifying or designing other structures for carrying out the same purposes of the present invention. It 
should also be realized by those skilled in the art that such equivalent constructions do not depart from the spirit and 
scope of the invention as set forth in the appended claims. The novel features which are believed to be characteristic 
of the invention, both as to its organization and method of operation, together with further objects and advantages will 

20 be better understood from the following description when considered in connection with the accompanying figures. It 
is to be expressly understood, however, that each of the figures is provided for the purpose of illustration and description 
only and is not intended as a definition of the limits of the present invention. 

BRIEF DESCRIPTION OF THE DRAWING 

25 

[001 2] For a more complete understanding of the present invention, reference is now made to the following descrip- 
tions taken in conjunction with the accompanying drawing, in which: 

FIGURE 1 is a logical diagram illustrating the principles of router virtual networking, according to an embodiment 
30 of the present invention. 

DETAILED DESCRIPTION 

[0013] In embodiments of the present invention, a host network router is logically partitioned into multiple virtual 

35 ' networking domains sharing a common operating system. FIGURE 1 is a logical diagram illustrating the principles of 
router virtual networking, according to an embodiment of the present invention. In the implementation of FIGURE 1 , a 
host router 10 is logically partitioned into v-net domains 12, 14, and 16 that are associated with networking systems. 
Each v-net 12, 14, 16 has a unique v-net ID address 13, 15, 17, in accordance with network protocols. Host router 10 
andeachofv-nets 12, 14, 16 are further logically subdivided into two spaces, shown in FIGU RE 1 separated horizontally 

40 by a solid line, namely a user level 1 8 and a kernel level 20 of the shared common operating system (OS), for example 
a version of FreeBSD. The present FreeBSD operating system runs on the host router Master Control Processor (MCP), 
described for example in U.S. Application Serial Number 09/703,057, entitled "System And Method For IP Router With 
an Optical Core," filed October 31 , 2000, cited above, the disclosure of which has been incorporated herein by refer- 
ence, and the dynamic routing protocol (DRP) application software runs on top of FreeBSD. 

45 [0014] An operating system contains within it logical notions called processes 22-26, for example Internet Manage- 
ment Application 22, DRP 23, 25, or Simple Network Management Protocol (SNMP) agent application 24, 26, running 
on v-nets 12, 14, and 1 6. Different individual v-nels can manage the same, different, single, or multiple processes. V- 
net domains 14 and 1 6, each running DRP and SNMP processes, are virtual routers, whereas v-net domain 1 2, running 
only an internal management application, is not a virtual router. The present FreeBSD operating system supports 

50 multiple processes, among which are DRP 23, 25, SNMP 24, 26, and Internal Management Application 22. Each 
process occupies some user level space 18 and also some operating system kernel level space 20. User level space 
18 includes the application and the values of all the application variables (not shown in FIGURE 1), whereas OS or 
kernel level space 20 of the process includes internal data that the kernel maintains with each process. Typical examples 
of internal kernel data include descriptors or descriptions of open files and the ID of the user that owns the process, 

55 attributes that are added to each process associated with a particular v-net. 

[0015] Among other things associated with a particular v-net are interfaces, for example interfaces 42-1 through 42-3 
associated with v-net 12. An interface represents for example a particular physical hardware Ethernet card, gigabit 
Ethernet card, or SONET line card interconnected with a remote router. This allows partitioning of host router interfaces, 



3 

3NSDCCIO: <EP 1271861A2_i_> 



EP 1 271 861 A2 



such that for example interfaces 42-1 through 42-3 contain v-net ID 13 of v-net 12 with which they are associated. V- 
net domain 12 maintains an interface list 42-0 pointing to interfaces 42-1 through 42-3. Similarly v-net domain 14 
maintains an interface list 43-0 pointing to interfaces 43-1 through 43-3 carrying v-net ID 15 of v-net domain 14, and 
v-net domain 16 maintains an interface list 45-0 pointing to interfaces 45-1 through 45-3 carrying v-net ID 17 of v-net 
5 domain 16. 

[0016] Each process 22-26 can create sockets, which are end points of communication associated with a process, 
for example sockets 32-1 through 32-3 associated with process 22 in v-net domain 12. A particular process can have 
more than one socket. Each socket has a v-net ID associated with it, for example sockets 32-1 through 32-3 each 
contain v-net ID 13 of v-net 12. In v-net 12, management application 22 maintains a descriptor table, for example file 

10 descriptor table 32-0 of v-net 12, holding references to sockets 32-1 through 32-3 and to files, which are each associated 
with specific application 22. Similarly, in v-net 14, DRP application 23 maintains descriptor table 33-0, holding refer- 
ences to sockets 33-1 through 33-3 and to files associated with application 23, and SNMP application 24 maintains 
descriptor table 34-0 holding references to sockets 34-1 through 34-3 and to files associated with application 24. Like- 
wise in v-net 16, DRP application 25 maintains descriptor table 35-0, holding references to sockets 35-1 through 35-3 

15 and to files associated with application 25, and SNMP application 26 maintains descriptor table 36-0 holding references 
to sockets 36-1 through 36-3 and to files associated with application 26. 

[0017] Sockets are partitioned basically according to the domain in which communication takes place. Each of the 
things done to the socket is interpreted in the context of the particu lar v-net in which the socket is created, and therefore 
the socket carries that particular v-net identifier. The process has a v-net identifier, because when a process creates 

20 a new socket, which it is able to do, each socket that it creates is then created in a process of that v-net identifier. For 
example, if a process is associated with v-net 0 creates a socket, then that socket is automatically associated with v- 
net 0, gets its routing tables from v-net 0, and can then use all of the interfaces that are assigned to v-net 0. A process 
can, however, change its v-net identifier and thereby its v-net association, for example by moving logically from v-net 
0 to v-net 1 , and can then create a new socket associated with v-net 1 , which uses routing tables and interfaces of v- 

25 net 1 , which are disjoint with the interfaces for v-net 0. 

[0018] Once a socket is created, it cannot be moved to another v-net, but remains in the domain in which it was 
created. However, a process, by changing its v-net identifier, can then create sockets in multiple domains. Conse- 
quently, a process can essentially communicate across domains by creating a socket in each one, but each socket, 
throughout its existence, is fixed in its original domain. Multiple sockets created by a process are distinctly different 

30 from a single socket that is simply interpreted in different ways. For example a single process can create ten distinct 
sockets in one domain and five distinct sockets in another domain. For example, socket 35-4 is created in v-net domain 
12 by DRP application 25 and carries v-net ID 13, although socket 35-4 is referenced in descriptor list 35-0 of DRP 
application 25, which is now in v-net domain 1 6. Likewise, socket 33-4 is created in v-net domain 12 by DRP application 
23 and thus carries v-net ID 1 3, although socket 33-4 is referenced in descriptor list 33-0, which is now in v-net domain 

35 1 4. A socket is destroyed when a process exits or when a process closes down the communication end point repre- 
sented by that socket. After a socket is destroyed, it is no longer associated with any domain, and the memory asso- 
ciated with it is freed. 

[001 9] If for example v-net 1 4 and v-net 1 6 are two networki ng domains of host router 1 0, and if v-net 1 4 is a production 
network carrying live traffic with production code in it, or production network connections carrying real customer traffic, 

40 then a socket associated with v-net 14 is operating in that v-nefs space and has routing tables 48 for that v-net to route 
live traffic. Consequently, if the socket were to select a particular IP address, that IP address would use production 
routing tables 48. A different socket in a different v-net 16 is for example used for a small test bed and contains a 
different set of routing tables 50. Accordingly, when a message is sent on v-net 16 with an IP address, that IP address 
is interpreted in the context of v-net 16 running the small test bed. 

45 [0020] Global variables are variables that are accessible to all the various logical contexts or threads of execution 
that are running concurrently within an operating system. Thus a global variable is not on the stack of a particular 
thread. Accordingly, all global variables are available to every process that is running within the operating system. 
Global variables include at least at the top level, for example, the IP address of a machine or a copy of the routing 
tables so that a process knows where to send packets. There are a certain set of global variables associated with the 

50 networking code, and in order to make the networking codes support partitioning, the set of global variables associated 
with networking are replicated, one copy 47 for each v-net domain, such that the operating system effectively contains, 
rather than one copy of the networking data structures, N instantionations of the networking stack, replicating all the 
various functions of the networking code, including replicated routing tables and replicated TCP control blocks linked 
together throughout the basic data structure. Thus, effectively all of the important variables in the networking system 

55 are replicated, so that they can be independently managed. This can be thought of as an operating system with N 
instantiations of the networking system. 

[0021] The basic approach of the v-net code is to take global variables that need to be replicated for each v-net 
. domain, and to make an array of them. As an example tcpstat, the tcp statistics structure, is declared in tcp_var.h struct 
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tcpstat{...} and defined in tcpjnput.cas struct tcpstat tcpstat. To have a separate set of statistics for each v-net domain 
requires changing the definition to struct tcpstat tcpstat[NVNET]an6 changing all references to index by the appropriate 
v-net domain number. 

[0022] To make v-net facility a configuration option, the declarations and references are encapsulated in macros. 
5 The macros generate arrays when v-nets are configured in and scalars when v-nets are deconfigured. As an example 
the tcpstat declaration becomes VDECL (struct tcpstat, tcpstaT), in which the first macro argument is the type, and the 
second macro argument is the name. It will be noted that the variable name is changed from tcpstat to tcpstaT. This 
convention is followed throughout the global variable generation, i.e., variables that are virtualized and global across 
more than one file are changed to have the final letter in their name capitalized. This is done for three reasons: 

w 

1) to differentiate global variables from local variables and/or types of the same name for readability, 

2) to ensure that all references to global variables are fixed appropriately (by causing a compile error if the variable 
name is not changed); and 

15 

3) to denote global variables plainly for possible future changes. 

[0023] References to virtualized variables are made using one of two macros, _v(name), or _V(name, index), where 
name is the variable name and index is the v-net domain index to be used. The macro _vuses a per CPU global index 

20 variable vnetindex. it will be noted that all references to virtualized variables must be made with these macros, without 
exception, so that the references are correct without requiring #ifdefs when v-nets are configured or deconfigured. 
[0024] In addition to defining a methodology that handles virtualization of variables, a selection is needed of the 
correct set of global variables to be replicated for each v-net domain, and the replicated variables need to be correctly 
referenced by macros in the appropriate v-net domain. For example, global variables can be identified by using a script 

25 that analyzes object to) files for the global variables they define, by code inspection, or by information from other 
sources (see for example the tables of global variables in TCP/IP Illustrated, Volume 2: The Implementation, Gary R. 
Wright and W. Richard Stevens, Addison-Wesley 1995, p. 64, 97, 128, 158, 186, 207, 248, 277, 305, 340, 383, 398, 
437, 476, 572, 680, 715, 756, 797, 1028, and 1051). 

[0025] The following Appendix A is basically a table of the global variables that are virtualized in some implementa- 
30 tions : listing the name and the purpose of the variable. The variables that are virtualized are generally marked "virtu- 
alized" in the table. Although virtualized variables shown in the table are usually marked "virtualized," other variables 
in the table have been analyzed but excluded from virtualization. All of the "virtualized" variables are essentially repli- 
cated, such that each v-net maintains its own set of these variables. Then macros, program conventions that allow 
textural substitution, are provided, such that everywhere a global variable is accessed, a replacement access is a 
35 macro reference selected from the correct set of variables based on the correct v-net. 

[0026] In the present embodiment, multiple networking domains are implemented by the same operating system, 
unlike previous approaches, in which for example a computer is subdivided into virtual domains that partition the hard- 
ware and run separate operating systems in each domain. 

40 



45 



50 
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APPENDIX A. VARIABLE ANALYSIS 

NOTE: In the Analysis/Disposition column, "Virtualizecf * means the variable becomes an array when vnets are 
configured (sec the description above); "Invariant" means a separate instance of the variable is not needed for 
different vnet domains; and "Not VirtualizetT means there was a choice about virtualization (e.g., whether a 
Tunable could have a different value in different domains), but the choice was made not to virtualize the 
variable. 



Variable 


Data Type 


Defining File 


Description 


Analysis/ 
Disposition 


Head 


static struct 
router info * 


igmp.c 


Head of router_info linked list 


Virtualized. 


Addmask_key 


static char * 


radix, c 


Temporary storage for 
rn addmask. 


Invariant. 


arp_allocated 


static int 


if_ether.c 


Total number of llinfo_arp 
structures allocated 


Virtualized. 


arp_inuse 


static int 


ifether.c 


Current number of llinfo_arp 
structures in use. 


Virtualized. 


arp_maxtries 


static int 


if_ether.c 


Tunable. Maximum number of 
retries for an arp request 


Tunable. Not 
virtualized. 


arp_proxyall 


static int 


if_ctlier.c 


Tunable. Enables forming a 
proxy for all arp requests. 


Tunable. Not 
virtualized 


arpinit_done 


static int 


if_ether.c 


Indicates initialization is done. 


Invariant 
Initialization 
handles all 
vnets. 


arpintrq 


struct ifqueue 


if_ether.c 


Arp interrupt request queue. 
Shared by all vnets. Vnet 

swiiuiiijig wncii puucu uxi 
queue. 


Invariant. 


arpt_down 


static int 


if_ether.c 


Tunable. No. of seconds 
between ARP flooding 
algorithm. 


Tunable. Not 
virtualized. 


arptjeeep 


static int 


if_ether.c 


Tunable. No. seconds ARP 
entry valid once resolved 


Tunable. Not 
virtualized. 


arpt_prune 


static int 


if_etheT.c 


Tunable. No. seconds between 
checking ARP list. 


Tunable. Not 
virtualized 


bpf__bufsize 


static int 


bpf.c 


Tunable. 


Tunable. Not 
virtualized. 


bpf_cdevsw 


static struct 
cdevsw 


bpf.c 


Table of entry point function 
pointers. 


Invariant 


bpf devsw instal 
led 


static int 


bpf.c 


Initialization flag. ; 


Invariant 


bpf_dtab 


static struct 
bpf d 

(NBPFILTER) 


bpf.c 


Descriptor structure, one per 
open bpf device. 


Invariant 


bpf_dtab_init 


static int 


bpf.c 


Another initialization flag. 


Invariant. 
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Variable 


Data Type 


Defining File 


Description 


Analysis/ 
Disposition 


bpf_iflist 


static struct 
bpfjf 


bpf.c 


Descriptor associated with each 
attached hardware interface. 


Invariant. 


rlns rf-cvsnaee 


static u Ion 2 


raw clns.c 


vwiuum lyaivudUlv J, niuuutu 

of receive space to reserve in 
socket 


"N^Ot v irti lali'y^H 
l^L/l rUlLLaiLcCU. 


clns_sendspace 


static u_Iong 


raw_clnsx 


Constant (patchable). Amount 
of send space to reserve in 
socket 


Not virtualized. 


Cilia USITCLjb 




raw pine r 
law l.liu.v. 


Mln/*HAn nAintaw i^r~\r e* Inr near 

ruacuou pointers ior cms u^er 

1 vUUCoUi 


invariant. 


clnsg 


struct clnsgJob 


raw_clnsx 


Global state associated with 

r~TJV rlnc r~ in/^lit/tinn lief h#»o/Hc 

i**y cina.G, lnciuQing usi acduo 

and counters. 


Virtualized. 


t irutlliLltj 


oUUtt livjUt-UC- 


raw <*ln< r 
law muA 


lillCl 1 LIU I iCUUCot UUCUC, 

Shared by all vriets. Vnet 

a *▼ 1 LVwlli-Ll^ UUUV W lik^i-I 1 Willi* * Cvl 

from queue. 


Hi V cLI 13X11. 


cinssw 


ctniPt trmtnen/ 
aUUvt piUlUiW 


tow fine <* 


ruiuiCiii 10 protoLUi entry 

points & associated data. 


invariant. 


CUUI11CI 


ctatir n intfvd f 




1 ftiinrPT tVyt it^ ttxt rpnort 
^UUUICI 1UI ipiW ICpUIL. 


v lrtuauzea. 


Hiv n^rv^nar^ 


static n lnntr 


fn divrrt c 


Ammint of rprriv^ cnarp tn 

reserve in socket. 


Invariant _ 




Qtatir n Inna 




Awniiflt rvf* epnH tnarp tn 

iiiilVJUl-ll VI OVllU djJdww W 

reserve in socket 


Tti variant 


divcb 


static struct 

inpebhead 


in divert c 


Hpfld of fnnch structures for 

divert processing. 




Hivrninfn 

Ul V LU1111U 


eta fir ctrir't 

inpebinfo 


in Hivprt r 


PrHinfo stnirtitrp for rlivert 

processing. 


Vfm i a Ii*7pH 


dst 


static struct 

lOcVafidT 1 


bpfx 


Sockaddr prototype. 


Invariant. 


CLI fJlCLlA 


charQ 


. ^ rc 


f^nnstant ?tnno for nrinrfc 


Invariant 


etherbroadcastad 
dr 


u_char [6] 


ifethersubrx 


Constant. Ethernet broadcast 

HnW' aHnYf»<i<i 
ijxia. auuicoo. 


Invariant. 


expire_upcalls_c 
h 


static struct 

fallout hnnHlp 


ip_mroutex 


Calicut handle for 


Virtualized. 


fcstab 


static u_short 




Constant. Table for FCS 
lookup. 


Invariant. 


frag_divertj)ort 


static u_short 


rp_inputx 


Divert protocol port. 
Conditional! v cnmnilf*d iwith 

v vllUi U VUMllf WliiUilLU 1 WILLI 

EPDIVERT. 


? 


fwdebug 


static int 


ip_fwx 


Tunable. Enables debug print. 


Not virtualized. 


fw_one_pass 


static uit 


ip_fwx 


Tunable. Enables accepting 
packet if passes first test. 


Not virtualized. 


fw_verbose 


static int 


ip_fw.c 


Tunable; controls verbosity of 
firewall debugging messages. 


Not Yirtualized 


fw_vcrbosc_limit 


static int 


ip_fwx 


Tunable. Limits amount of 
logging. 


Not vinualized. 


have encap tnnn 
cl 


static int 


ip_mxoutex 


Indicates presence of an 
encapsulation tunnel. 


Virtualized. 


icmpbmcastecho 


static int 


ip_icmpx 


Tunable flag. Disables 
broadcasting of 1CMP echo and 
tirnestarrip packets. | 


Not virtualized. 
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Variable 


Data Type 


Defining File 


Description 


Disnn^itinn 


icmpdst 


static struct 
sockaddr in 


ip_icmp.c 


Saves the source address tor 
ifaof ifpforaddr. 


Virtualized. 


icmpgw 


static struct 
sockaddr_in 


ip_icmp.c 


Holds the ip source address in 
icmp_input. 


Vutuaiized. 
May not be 
necessary 


icmplim 


static int 


ip_icmp.c 


Tunable. I CMP error-response 
band with limiting sysctL 


Not vutuaiized. 


icmpmaskrepl 


static int 


ip_icmp.c 


Tunable flag. Enables ICMP 
mask replacement 


Not virtualized. 


icmpprintfs ! 


int 


ipicmp.c 


Enables printfs in icmp code. 


Not virtualized. 


icmpsrc 


static struct 
sockaddr_in 


ip_icmp.c 


Holds the ip dest address in 
icmp_input. 


Virtualized. 
May not be 
necessary 


icmpstat 


static struct 
icmpstat 


ip_icmpx 


Icmp statistics. 


Virtualized. 


if_indeX 


int 


if.c 


Number of configured 
interfaces. 


Vutuaiized. 


if_indexiiM 


static int 


if.c 


Number of entries in 
ifhet addrS array. 


Virtualized. 


imeT 


struct ifnethead 


if.c 


Head of list of imet structures. 


Virtualized. 


imet addrS 


struct iffaddr ** 


if.c 


Array of pointers to link level 
interface addresses. 


Virtualized. — 


ifqmaxlen 


int 


if.c 


Constant Maximum queue 
length for interface queue. 


Invariant. 


igmp_all_hosts _g 
roup 


static u_long 


igmp.c 


Host order of 

INADDR_ALLHOSTSJ3ROU 
P constant 


Invariant 


igmp_all_rtrs _gr 
oup 


static u_long 


igmp.c 


Host order of 

INADDR_ALLRTS_GROUP 
constant. 


Invariant 


igmp_tiraers are 
_running 


static int 


igmp.c 


Flag indicating any igmp timer 
is active. 


Virtualized. 


igmprt 


static struct route 


igmp.c 


Temporary variable. 


Invariant 


igmpstat 


static struct 
igmpstat 


igmp.c 


Igmp statistics. 


Virtualized. 


in_ifaddrheaD 


struct 

in ifaddrhead 


ip_inputc 


Head of in_ifaddr structure list 


Virtualized. 


in_interfaces 


static int 


in.c 


Incremented each time a non- 
loopback interface is added to 
in ifaddrheaD. Not read. 


Invariant 
Never read. 
Dead code. 


in_muitiheaD 


struct 

irwnultihead 


ln.c 


Head of list of 
in_multistructures (multicast 
address). 


Virtualized. 


inctclerrmap 


u _char Q 


ip_input.c 


Array of constants (error 
numbers). 


Invariant 


inetdomain 


struct domain 


in_proto.c 


Pointers to switch table, 
initialization, etc. for internet 
domain. 


Invariant. 


inetsw 


struct protosw 


in_proto.c 


Pointers to entry points for 
various internet protocols. 


Invariant 


inited 


static int 


if.c 


Flag indicating initialization 
has been performed. 
Initialization does all vnets. 


Invariant 
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Variable 


Data Type 


Defining File 


Description 


Analysis/ 
Disposition 


ip_acceptsourcer 
oute 


static uit 


ip_inputc 


Tunable flag. Enables 
acceptance of source routed 
packets. 


Tunable. Not 
virtualized. 


ip_defft] 


int 


ip_inputc 


Tunable. Default time to live 
from RFC 1340. 


Tunable. Not 
virtualized. 


ip_divert_cookiE 


u intl6 t 


ip_divertc 


Cookie passed to user process. 


Virtualized. 


ip_divert_porT 


u_short 


ip_divertc 


Global "argument" to 
div_input. Used to avoid 
changing protorype. 


Virtualized. 


ip_dosourceroute 


static int 


ip_input.c 


Tunable flag. Enables acting as 
a router. 


Tunable. Not 
virtualized. 


ip_fw_chaiN 


struct ip fw head 


ip_fw.c 


Head of ip firewall chains. 


Virtualized 


ip _fw_chk_ptr 


ipfwchkj * 


ip_input.c . 


IP firewall function callout 
pointer; value depends on 
loading fw module. 


Invariant 


ip_rw_ctl__ptr 




ip_input.c 


IP firewall function callout 
pointer, value depends on 
loading fW module. 


Invariant 


ip_fw_default_ru 
IE 


struct 

ip_fw_chain* 


ip_fw.c 


Pointer to default rule for 
firewall processing. 


Virtualized. 


ip_fw_fwd_addR 


struct 

sockaddr in* 


ip_irrputc 


IP firewall address. 


Virtualized. 


ip_ID 


u_short 


ip_output.c 


IP packet identifier 
(increments). 


Virtualized. 


ip_racast_src 


ulong (*)(int) 


jp_mroute.c 


Pointer to function; selection 
depends on compile options. 


Invariant. 


ip_mforward 


int(*)(struct ip *, 
struct ifhet *,...) 


ip_mroute.c 


Function pointer set by module 
installation. 


Invariant. 


ip_mrouteR 


struct socket * 


ip_mroute.c 


Socket of multicast router 
program. 


Virtualized. 


ip_rnrouter_done 


int (*)(void) 


ip_mroute.c 


Function pointer set by module 
installation. 


Invariant. 


ip_mrouter_get 


int (*)(struct 
socket *, struct 
sockopt *) 


ip_mroute.c 


Function pointer selected by 
compile options. 


Invariant 


ip_mrouter_set 


int (*)(struct 
socket *, struct 
sockopt *) 


ip_mroute.c 


Function pointer selected by 
compile options. 


Invariant 


ip_nat_clt_ptr 


ip_nat_ctlj * 


ip_inputc 


IP firewall function callout 
hook; set by module install. 


Invariant 


ip_natjptr 


ip_nat_t • 


ip_inputc 


IP firewall function callout 
hook; set by module install. 


Invariant. 


ip_nhops 


stanc int 


i-n innilt f* 

ip_mpui.v 


Unn rrni-nt fc\T Tsrpviou? source 

route. 


Virtualized. 


ip_protox 


u char 

[PROTO_MAX] 


ip_input.c 


Maps protocol numbers to 
inetsw array. 


Invariant 


ip_rsvpD 


struct socket * 


ip_input.c 


Pointer to socket used by rsvp 
daemon. 


Virtualized. 


ip_rsvp_on 


static int 


ip_input.c 


Boolean indicating rsvp is 
active. 


Virtualized. 


ip_srcrt 


struct ip_srcrt 


ip_inputc 


Previous source route. 


Virtualized. 


ipaddR 


struct 

sockaddr in 


ip_input.c 


Holds ip destination address for 
option processing. 


Virtualized. 
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Variable 


Data Type 


Defining FUc 


Description 


Analysis/ 
Disposition 


ipflowS 


static struct 
ipflowhead 


ip_flow.c 


Hash table head tor rptlow 
structs. 


v lxtuaiizea. 


ipflow_active 


static int 


ip_flow.c 


Tunable, Enables last 
forwarding" flow code. 


Invariant 


ipflow_inuse 


static int 


ip_flow.c 


Count of active flow structures. 


Virtualized. 


ipforward_rt 


static struct route 


ip input.c 


Cached route fox ip forwarding. 


Virtualized. 


iforwarding 


int 


ip_inputc 


Tunable that enabales ip 
forwarding. 


Virtualized. 


ipintrq 


struct ifqucuc 


ip_Jnputc 


Ip interrupt request queue for 
incoming packets. Vnet set 
when packets dequeued 


Invariant 


ipponfirstauto 


static int 


ip_pcb.c 


Bounds on ephemeral ports. 


Invariant. 


ippon_hifirstauto 


static int 


ip_pcb.c 


Bounds on ephemeral ports. 


Invariant. 


ippon hilastauto 


static int 


ip__pcb.c 


Bounds on ephemeral ports. ; 


Invariant 


ippon las tauto 


static int 


ip_pcb.c 


Bounds on ephemeral ports. 


Invariant: 


ippon_lowfirstau 
to 


static int 


ip_pcb.c 


Bounds on ephemeral ports. 


Invariant. 


ipport_lowlastaut 

0 


static int 


ip_pcb.c 


Bounds on ephemeral ports- 


Invariant 


ipprintfs 


static uit 


ip_inputc 


Flag for debug print. 


Invariant. 


ipq 


static struct ipq 
[IPREASS NHA 
SH] 


ip_inputc 


Head of ip reassembly hash 
lists. 


Virtualized. ~ 


ipqmaxlen 


static int 


ip_inputc 


Patchable constant that sets 
TpaYimiim queue length for 
ipintrq. 


Invariant 


isendredirects 


stanc int 


ip_inputc 


Tunable that enable sending 
redirect messages. 


Invariant 


istaT 


struct ipstat 


ip_input.c 


Ip statistics counters. 


Virtualized. 


k_igmpsrc 


static struct 
sockaddr in 


rp_mroute.c 


Prototype sockaddr_in. 


Invariant 


last_adjustcd_tim 
eout 


static hit 


ip_rmx.c 


Time value of last adjusted 
timeout 


Virtualized. 


last__encap_src 


static ujong 


jp_mroutex 


Cache of last encapsulated 
source address? 


Virtualized. 


last_encap_vif 


struct vif * 


rp_mroutc.c 


Last encapsulated volume tag . 
(vif). 


Virtualized. 


last_zeroed 


static mt 


radix. c 


Number of bytes zeroed last 
time in adchnask_key. 


Invariant 


legal_vif_num 


intO(iat) 


ip_mroute.c 


Pointer to function selected by 
module installation. 


Invariant 


UmfojirP 


struct 

llinfo_arp_hcad 


if_ether.c 


Head of Uinfo_arp linked list 


Vrrtualized. 


log_in_vain 


static int 


tcp — inputc 
udp_usrreq.c 


Tunablcs that enable logging of 
"in vain" connections. 


Invariant 


loif 


struct ifhet 
[NLOOP] 


ifjoop.c 


Array of ifhet structs fro 
loopback device. One per 
device, therefore invariant. 


Invariant 


mask_mhead 


struct 

radix_node_head 
* 


radix. c 


Head of mask tree. 


Invariant. 


maxjceylcn 


static int 


radix, c 


Maximum key length of any 
domain. 


Invariant. 
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Variable 


Data Type 


Defining File 


Description 


Analysis/ 
Disposition 


.maxmpq 


static int 


ip_inputc 

* 


Constant (nmbclusltcr/4) that is 
maximum number of ip 
fragments waiting assembly. 
Note: should this be scaled by 
VNET? 


Invariant? 
Scaled? 


mfctable 


static struct mfc * 
[MFCTBLSIZ] 


ip_mroute.c 


Head of mfc hash table. 


Virtualized. 


rnrt_ioctl 


int(*)(int, 
caddr_t, struct 

pTDC*) 


ip_mroute.c 


Function pointer selected by 
module initialization- 


Invariant. 


mrtdebug 


static u int 


ip_mroute.c 


Enables debug log messages. 


Invariant. 


mrtstat 


static struct 
mrtstat 


tp_mroutex 


Multicast routing statistics. 


Virtualized. 


mtutab 


static int [] 


ip_icmpx 


Static table of constants. 


Invariant 


multicast decap 
if 


static struct ifhet 
[MAXVIFS] 


ip_mroutcx 


Fake encapsulates interfaces. 


Virtualized. 


multicast__encap_ 
iphdr 


static struct ip 


ip w mroutex 


Multicast encapsulation header. 


Invariant 


nexpire 


static u char 
[MFCTBLSIZ] 


ipjmroute.c 


Count of number of expired 
entries in hash table? 


Virtualized. 


aipq 


static int 


ip_inpuLc 


Number of ip fragment chains 
awaiting reassembly. 


Virtualized. - 


nonnal chars 


static char [] 


radixx 


Static table of mask constants. 


Invariant. 


aousrxeqs 


static struct 
prjisrreqs 


in_proto.c 
ipx^proto.c 


Static structure of null function 
pointers. 


Invariant 


null_sdL96 


static struct 
sockaddr_dl 


ifether.c 


Static null sockaddr_dl 
structure. 


Invariant 


numvifs 


static viii_t 


ip_mroutex 


Number of virtual interface 
structures. 


Virtualized. 


old_chk_ptr 


static 

ip_fw_chk_t 


ip_fwx 


Function pointer holding 
previous state when module 
loads. 


Invariant 


old_ctl_pti 


static ip_fw_cti_t 


ip_fw.c 


Function pointer holding 
previous state when module 
loads. 


Invariant 


paiityub 


static unsigned 
[3] 


pppjtyx 


Static array of parity constants. 


Invariant 


pim_assert 


static int 


ip_mroutex 


Enables pirn assert processing. 


Virtualized. 


ppp_comprcssors 


staric struct 
compressor [8] 


if_ppp,c 


Static list of known ppp 
compressors. 


Invariant 


ppp_softc 
pppdisc 


struct ppp_softc 
[NPPP] 


ifjjpp.c 


Array of softc structures for 
ppp driver; one per device. 


Invariant. 


raw_recvspace 


static u_long 


raw_cbx 


Patchable constant that is 
amount of receive space to 
reserve in socket 


Invariant 


raw_sendspace 


static u_long 


raw_cbx 


Patchable constant that is 
amount of send space to reserve 
in socket. 


Invariant 


rawusrreqs 


struct protosw 


rawusrreqx 


Table of function pointers. 


Invariant 


rawcb_tisT 


struct 

raweb list head 


raw_cbx 


Head of raweb (raw prototocol 
control blocks) list. 


Virtualized 


rawclnsdomain 


struct domain 


raw clnsx 


Table of function pointers. 


Invariant. 
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Variable 


Data Type 




ueicripiion 


Analysis/ 
is imposition 


5 


rip_recvspace 


static u_long 


raw_ip.c 


Tunable, amount of receive 
space to reserve in socket. 


Tunable. Not 
virtualized. 




rip_sendspace 


static ujong 


raw_ip.c 


Tunable, amount of send space 
to reserve in socket. 


Tunable. Not 
virtualized. 




rip_usrreqs 


struct pr_usrreqs 


raw_ip.c 


Table of function pointers. 


Invariant 


10 


ripcb 


static struct 
inpcbhead 


raw_ip.c 


Head of raw ip control blocks 


Virtualized. 




ripcbinfo 


struct inpcbinfo 


raw_ip.c 


Pcb info, structure for raw ip. 


Virtualized. 




ripsic 


static struct 
sockaddr in 


raw_ip.c 


Static temporary variable in 
rip_input 


Invariant. . 


15 


rn_mkfreelist 


static struct 
radix mask * 


radix.c 


Cache of tree radix_mask 
structures. 


Invariant 




rn_ones 


static char * 


radix.c 


One mask computed from 
maximum key length. 


Invariant 




mzeros 


static char * 


radix.c 


Zeros mask computed from 
maximum key length. 


Invariant 


20 


ro 


static struct route 
ro 


ip_rnroute.c 


Temporary variable to hold 
route. 


Invariant. 




route_cB 


struct route_cb 


route.c 


Counts on the number of 
routing socket listeners per 
protocol. 


Virtualized. 


25 


route_dst 


static struct 
sockaddr route 


rtsockx 


Null address structure for 
destination. 


Invariant. 




route_proto 


static struct 
sockproto 


rtsock.c 


Static prototype of structure 
used to pass routing info. 


Invariant 




route_src 


static struct 
sockaddr 


rtsock.c 


Null address structure for 
source. 


Invariant. 


30 


route_usrreqs 


static struct 
pr_usrreqs 


rtsockx 


Table of function pointers for 
entry points. 


Invariant 




routedomain 


struct domain 


rtsockx 


Table of function pointers for 
entry points. 


Invariant 


35 


route_alert 


static struct mbuf 
* 


igmp.c 


Statically constructed router 
alert option. 


Invariant. 


routesw 


struct protosw 


rtsock.c 


Table of function pointers for 
entry points. 


Invariant. 




rsvp_oN 


int 


ip_inputc 


Count of number of open rsvp 
control sockets. 


Virtualized. 


40 


rsvp_src 


static struct 
sockaddr_in 


ip_mroute.c 


Sockaddr prototype. 


Invariant. 




rsvpdebug 


static u int 


ipmroute.c 


Enables debug print. 


Invariant. 




rtjableS 


struct 

radix_node_head 
* [AF_MAX+t] 


route.c 


Head of the routing tables (a 
table per address family.) 


Virtualized. 


45 


rtq_minreallyold 


static int 


in_rmx.c 


Tunable; minimum time for old 
routes to expire. 


Invariant 




rtqj-eallyold 


statinc int 


in_rmx.c 


Amount of time before old 
routes expire. 


Virtualized, 


50 


rtq_tirneout 


static int 


in_rmx.c 


Patchable constant timeout 
value for walking the routing 
tree. 


Invariant 




rtq_toomany 


static int 


in_rmx.c 


Tunable that represents the 
number of active routes in the 
tree. 


Invariant 
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Variable 


Data Type 


Defining File 


Description 


Analysis/ 
Disposition 


rtstaT 


struct rtstat 


route.c 


Routing statistics structure. 


Virtualized 


rttrash 


stanr int 

slaLlv lilt 


route, c 


^umheT of rtentrvQ nnt linWcd 

to the routing table. Never read, 


Dead code Mot 

virtualized. 


sa_zero 


struct sockaddr 


rtsock.c 


Zero address return in error 

VfuliUlUUlU* 


Invariant 


sin 


cwtir cmirt 

5 Itt LJlr -> Li U w l 

sockaddr_inarp 


if ptViPr c 

if mroute.c 


Sockaddr nrotntvne nassed to 
rtallocl. 


Invariant 


sl_softc 


ctarir Qtnirt 
awi tic 3uuwi 

sLsoft [NSL] 


if si.e 


Softc stnichire fnr <;Hd driver* 
one per device. 


Invariant 


slip disc 


QtHflC ^tTTlf*t 
alttliVr 9UUV.I 

linesw 


if sl.c 


Table of function no inters to 
slip entry points. 


Invariant 


srctun 


static int 


ip_inroute.c 


Counter throttling error 
message to lot? 


Invariant. 


subnetsarelocal 


static int 


in.c 


Tunable flag indicating subnets 

<U v IwwIUi 


Virtualized 


tbfdebug 


static u int 


ip_mroute.c 


Tbf debug level. 


Invariant 


tDitaole 


ptotir ctnirt ftai 
SLdUL oUULl LUi 

[MAXVIFS] 




Token hiirlreT filter ^tnictirre.s 

1 V)&Wll UUb&Vi 11 1 LCI 3UUVHUW. 


Vrrtualiized 


tcB 


struct inpebhead 


tcp_inputx 


Head structure for tcp peb 
suueuxres. 


Virtualized. 


tcbinfO 


struct inpebinfo 


tcp_input.c 


PCB info structure for tcp. 


Virtualized. 


tcp_backoff 


int [] 


tcp_tiiner.c 


1 aole oi tunes ior tcp Dactcu 
processing. 


jji variant. 


tcp_ccgeN 


tcp_cc 
(u_inU2 tj 


tcp_inputc 


Connection count (per rfc 

10***+). 


Virtualized 


tcp_delack_enabl 
ed 


int 


tcp_input.c 


Tunable that enables delayed 

aCOlOWiCQgliiCIllo. 


Tunable. Not 
v iiiiiamcLu 


tcp_do_rfcl323 


static int 


tcp_subr.c 


Tunable enables rcf 1323 

^WlnQOW SCaimg oUU 

times tamps.) 


Tunable. Not 

V 11 IU41L6CU.. 


tcp_do_rfcl644 


static int 


tcp_subr.c 


Tunable enables rfc 1644. 


Tunable. Not 

vinuAiucu. 


tcpjceepcnt 


static int 


tcp_timer.c 


Patchable constant for 

it unum uuiuuci ui piuuvo 

before a drop. 


Invariant 


tcp^kecpidlc 


mi 




TimaHle value for keen alive 

idle timer. 


Tunable Not 
virtualized 




int 


rni rimer c 


Tunable value for initial 
connect keep alive. 


Tunable. Not 
virtualized. 


tcp_maxidle 


int 


tcp_timcr.c 


Product of tcp_keepcnt * 

ten keeorntvl* recorrrnuted in 

slow timeout. 


Invariant 


tcp_maxpersistidl 
c 


static int 


tcp_timerx 


Patchable constant that is 
default time before probing. 


Invariant. 


tcp_mssdflt 


int 


tcp_subr.c 


Tunable default maximum 
segment size. 


Tunable. Not 
virtualized. 


tcp_noW 


u_long 


tcp_input.c 


500 msec, counter for RFC 1323 
timestamps. 


Virtualized. 


tcp_ourflags 


u char 

[TCP NSTATES 
] 


tcp;_fsm.h 


Static table of flags in 
tcp_output. 


Invariant 


tcp_ntdflt 


static int 


tcp subr.c 


Tunable. Dead code, value not 


Invariant Dead 
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Variable 


Data Type 


I >. fiiing FUe 


Description 


Analysis/ 
Disposition 










accessed. 


code. 


5 


tcp_sendspace 


u_long 


tcp_usrreq 


Tunable value for amount of 
send space to reserve on socket 


Tunable. Not 
virtualized. 




tcpjotbackoff 


static int 


tcp_timer.c 


Sum of tcp_backoff. 


Invariant. 




tcp_usrrcqs 


struct pr_usrreqs 


tcp_usrreq.c 


Table of function pointers for 
tcp user request functions. 


Invariant 


10 


tcprcxmtihresh 


static int 


tcpjnputc 


Patchable constant; number of 
duplicate acks to trigger fast 
retransmit 


Invariant 




tcpstaT 


struct tcpstat 


tcp_inputc 


TCP statistics structure. 


Virtualized. 




tun_cdevsw 


struct cdevsw 


if_tun.c 


Table of function pointers for 


Invariant 


15 








tunnel interface entry points. 




tun devsw instal 
led 


static int 


if_tun.c 


Flag uidiating tun devsw table 
installed. 


Invariant 




tunctl 


static struct 

tun_softc 

[NTUN] 


if_tun.c 


Softc structure for tunnel 
interface; one per device. 


Invariant 


20 


tundcbug 


static int . 


if tun.c 


Flag enables debut print 


Invariant 




udb 


static struct 
inpcbhead 


udp_usrreq.c 


UDP inpcb head structure. 


Virtualized 




udbinfo 


static struct 
inpcbinfo 


udp^usrreq.c 


UDP inpcb info, structure. 


Virtualized. ~ 


25 


udp in 

r — 


static struct 
sockaddr_in 


udp_usrreqx 


Prototype sockaddr for 
AF INET. 


Invariant. 




udp recv space 


static u_long 


udp_usrreq.c 


Tunable; amount of receive 
space to reserve on socket 


Tunable. Not 
virtualized. 




udp sendspace 


static u_long 


udp_usrreq.c 


Tunable; amount of send space 
to reserve on socket. 


Tunable. Not 
virtualized. 


30 


udp_usrreqs 


struct pr_usrreqs 


udp_usrreq.c 


Table of function pointers for 
entry points. 


Invariant 




udpcksum 


static int 


udp_usrreqx 


Tunable; enables udp 
checksumrning. 


Tunable. Not 
virtualized. 




udpstat 


struct udpstat 


udpjisrreq.c 


Udp statistics structure. 


Virtualized. 


35 


useloopback 


static int 


if_ether.c 


Tunable; enables use of 
loopback device for localhost 


Tunable. Not 
virtualized. 




version 


static int 


ip_mroute.c 


Version number of MRT 
protocol. 


Invariant 




viftable 


static struct vif 


ip_mroutc.c 


Table of vifs (virtual interface 


Virrualized. 






[MAXVIFS] 


structure). 




40 


zeroin addr 


struct in addr 


in_pcb.c 


Zero'd internet address. 


Invariant 



[0027] Although the present invention and its advantages have been described in detail, it should be understood 
that various changes, substitutions and alterations can be made herein without departing from the spirit and scope of 

45 the invention as defined by the appended claims. Moreover, the scope of the present application is not intended to be 
limited to the particular embodiments of the process, machine, manufacture, composition of matter, means, methods 
and steps described in the specification. As one of ordinary skill in the art will readily appreciate from the disclosure of 
the present invention, processes, machines, manufacture, compositions of matter, means, methods, or steps, presently 
existing or later to be developed that perform substantially the same function or achieve substantially the same result 

so as the corresponding embodiments described herein may be utilized according to the present invention. Accordingly, 
the appended claims are intended to include within their scope such processes, machines, manufacture, compositions 
of matter, means, methods, or steps. 

55 Claims 

1 . A system of virtual router domains comprising: 
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a host router 10 running a common operating system 18, 20; 

a plurality of virtual router domains 1 2, 1 4, 1 6 and processes 22, 23, 24, 25, 26 logically partitioned within said 
host router each said virtual router domain having a unique domain ID address 13, 15, 17 and an independent 
replica array of all virtualized variables across said common operating system, each said process running in 
5 a said virtual router domain independently of all other said virtual router domains on top of said common 

operating system; and 

said global variables being accessed by macro references in each said virtual router domain. 

2. The system of claim 1 wherein said common operating system runs on a master control processor within said host 
w router. 

3. The system of claim 1 wherein said plurality of processes comprise routing software applications 23, 24, 25 ; 26. 

4. The system of claim 1 further comprising a plurality of interfaces 42, 43, 45 partitioned interchangeably among 
15 said virtual router domains, such that a particular interface is associated with only one such virtual router domain 

at one time, but can be repartitioned among said virtual router domains to reconfigure said host router. 

5. The system of claim 4 wherein said interface is an interlace port of said host router. 

20 6. The system of claim 5 further comprising a socket 32, 33, 34, 35, 36 created by at least one said process, said 
socket being associated exclusively with the virtual router domain in which it is created and containing said unique 
domain ID address of said domain in which it is created. 

7. The system of claim 6 wherein each of said virtual router domains maintains an independent routing table 46, 48, 50. 

25 

8. The system of claim 7 wherein each said socket uses the routing table of said virtual router domain in which said 
socket is created. 

9. The system of claim 8 wherein a failure of one of said plurality of said virtual router domains does not adversely 
30 affect a different one of said plurality of said virtual router domains. 

10. A method of logically partitioning a host router 10 into virtual router domains 12, 14 : 16, comprising: 

configuring the kernel 20 of a single common operating system 1 8, 20 running in said host router 1 0; 

35 configuring in a plurality of virtual router domains 12, 14, 16 within said host router; 

identifying each said virtual router domain by a unique domain index number 13, 15, 17; 
generating an independent identical set of replica arrays of global variables for each virtual router domain; and 
associating a process 22, 23, 24, 25, 26 with each said virtual router domain of said host router, such that said 
processes run in said virtual router domains independently of one another on top of said single common op- 

40 erating system of said host router. 
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33, 34, 35 36 and host router interfaces 42, 43, 45, each 
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references. A v-net facility can separate route tables 46, 
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tables and can avoid conflicts between internal and ex- 
ternal I P addresses 13,15,17 that share the same iden- 
tifier. For example a common FreeBSD operating sys- 
tem supports a dynamic routing protocol (DRP) applica- 
tion 23, 25. Each v-net runs an independent copy of the 
DRP software and is logically independent. A failure in 
one DRP copy does not adversely affect other copies. 
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